@jcaron Thanks for reply. I'm using a private network with Chirpstack and Laird gateway. Yes I know not to use Class C when in deepsleep. Our network is not used in winter (vineyard irrigation) and during this down time we want to sleep our nodes to save battery drain as we have low solar radiation in winter also. We are therefore not sending/receiving messages when in deepsleep. We have been successfully running Class C with 60 nodes for over 2 years, our only issue has been battery life which we are now trying to address. I will try and capture gateway log and post back here. Thanks

@mnovella Hello Thus, we can say that currently the LoPy4 does not support RejoinRequest natively, and that for it to happen the LoRa Module would have to be v1.1 compliant. Is this correct? LoPy AND LoraWAN operator have to be conform to 1.1 specification to use it. If yes, then given it's not natively supported, the responsibility for rejoining, etc. would fall on the application programmer (that is, me, or the code my LoPy has), just like you said that you start a join procedure after X time of not getting a downlink. Am I right? Yes, that's i do, after two week if no downlink as been recevied the device do a new OTA join request The 1.1 specs say that: "Once activated a device MAY periodically transmit a Rejoin-request message on top of its normal applicative traffic" It's very important when reading ISO/RFC/ETSI/official specification to be veray careful to the use of 'MUST',"MAY" and 'SHOULD" and there's indeed meaning. The low-level stack MUST support processing RejoinRequest but it's not mandatory that the application use it or is allowed to use it. That "MAY" part was the one that made me dubious if it was supported by the device or not... so I guess that even if/when Pycom supports LoraWAN 1.1 it will be up to Pycom to decide if/when to do the RejoinRequest if I'm not mistaken... I don't know what pycom will do when they will working to 1.1 port, but for me it's a "No" if i have had to vote, sending a new RejoinRequest is IMHO and application job and not a low-level stack/driver job. However, RejoinRequest is not send by a device, it's send by the network. When you do roaming (even in same country) you cant be in a specific area where some frequence channel is unusable (jammed), the network send to the device a RejoinRequest, the device perfom a new joinrequest and in the answer it receive a new channel list used in the area (frequency plan). If your device is static you don't have to think about this. My device perform new joinrequest as it's a moved device and can be for a long time out-of-network and when it come back is framecounter is far from when it leave the network and we don't receive anymore it's frame if we don't do a new joinrequest.

@mfalkvidd Hi, tks for the reply. Ok, that explains the problems that I have.

@weingami Hi, I deployed hotfix and tested wifi, sigfox and lora connections. I correctly received the data. We need to test more things and there are a few more bugs, that we know and we're about to fix now.

@harish-kumar Is it a 'Class-A' device? RX window timing can be an issue.

@bnjroos Yes, the RX1 and RX2 delay are specified in the LORaWAN regional settings. I did not look that up for every region, but the ones I recall use 5 and 6 seconds for OTAA join, and 1 and 2 seconds for other downlink messages as default.

@jcaron oh thank you. I will do that. And I need a small help from you. In this code, I am trying to start my downlink once in a day. So I am using this code. import time a = time.localtime() hour = a.tm_hour minutes = a.tm_min if hour == 10 and minutes == 40: print('{0}:{1}'.format(hour, minutes)) But it's not working properly. Do I have to change some conditions ?

@robert-hh Thank you so much ! I got the output.

@harish-kumar Well, you're not sleeping, so you shouldn't need to nvram_save/restore, but you're re-creating the LoRa object (twice!) in your loop, using two different modes (raw LoRa and LoRaWAN), and re-joining each time, so no wonder your frame counters get re-initialised. I'm really not sure you can use the current LoRa stack like this to achieve what you want. I'm quite certain it would require some extensive changes to the stack, especially if you really want to maintain true LoRaWAN compatibility (i.e. including ADR, MAC commands, etc.).

@rskoniec Hi, Only one of my Gateways out of two accepted join request, but still on the terminal I got the message as not yet joined. I saw the device eui displayes in Gateway join request message is APP eui which was false. I included device eui also in my code(Also I cant be very sure if it is what got my device to join but it worked for me). By the way I used sample code available on pycom docs for LoRaWAN OTAA. # create an OTAA authentication parameters device_eui = binascii.unhexlify('FFFFFFFFFFFFFFFFF') app_eui = binascii.unhexlify('FFFFFFFFFFFFFFFFF') app_key = binascii.unhexlify('FFFFFFFFFFFFFFFFF') # join a network using OTAA (Over the Air Activation) lora.join(activation=LoRa.OTAA, auth=(device_eui, app_eui, app_key), timeout=0) # wait until the module has joined the network while not lora.has_joined(): time.sleep(2.5) print('Not yet joined...') # create a LoRa socket s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) # set the LoRaWAN data rate s.setsockopt(socket.SOL_LORA, socket.SO_DR, 5) # make the socket blocking # (waits for the data to be sent and for the 2 receive windows to expire) s.setblocking(True)

@thomand1000 Have been looking at power consumption and have similar issues to what is reported here have 200mA in main program then 190 to 150 mA for 30 sec before dropping to deep sleep. In first cycle deep sleep current is 200 micro amps. In subsequent cycles the deep sleep current is 30 mA. Have tried turning everything off without change. Have same issue with LTE but don't have a SIM. Agree that things should not be instantiated by default but as required.

@jcaron Thanks a lot , limiting the channels to 0-8 and 64 ( for join/accept) did the trick for now.

@jcaron Hi Jcaron, Thanks for your explaination. We'll make te intervals longer so that we don't breach the regulations. I understand what your saying, but could you describe how you calcluate the collision rate? The strange thing is, that almost every time it is a single node who is not recieved well by the gateway. Not always two nodes at the same time. They are indeed close to each other, but we're now testing it with one node, to see how that works. We'll add a random interval. I'll post if this changes solved our problem.

@jmarcelino Thanks, it works!

@misterlisty it's an optional parameter on the LoRa constructor which enables ADR (adaptive data rate), which is a LoRaWAN features which enables the node and network to adjust parameters (the most important being the data rate, but channels lists as well). Some MAC commands sent by the network are only honoured by the LoPy if ADR is enabled. However @jmarcelino says the network doesn't send those commands anyway, so it may not be useful. Also note that the current firmware version does not correctly preserve channel masks during deep sleep.

Did you ever get it work? Any advise for me, as I am in the exact same situation?

@wstallwood As far as I know you can’t do it directly from micropython, but you could easily build a custom image from source adding a few logs where appropriate.

I live in the Netherlands. I am about 1.6 km away from a gateway. The response after joining is: { "time": "2018-01-17T10:17:07.155968027Z", "frequency": 867.3, "modulation": "LORA", "data_rate": "SF7BW125", "coding_rate": "4/5", "gateways": [ { "gtw_id": "eui-008000000000aa8a", "timestamp": 2268423667, "time": "2018-01-17T19:09:11.459706Z", "channel": 4, "rssi": -117, "snr": -3, "latitude": 53.20986, "longitude": 6.54523, "altitude": 15 } ] }